1. Technical Field
The present invention relates in general to an improved data processing system and in particular to a method and system for providing a client/server interface to a programming language. Still more particularly, the present invention relates to a method and system for providing client/server support which permits a server to wait for client requests and to read and set client variables.
2. Description of the Related Art
In the art of data processing system programming, "client/server" interaction is becoming an increasingly popular form of software architecture. As utilized herein, "client/server" interaction is a relationship between two software processes, which may be running on the same data processing system or on different data processing systems which are coupled via a network system. The "server" process is a provider of services. The "client" process is a consumer of services. Client/server interaction provides a clean separation of function between processes based on the idea of service. Some of the reasons for this increase in popularity are discussed below.
A server may service many clients at the same time and regulate their access to shared resources. Clients typically initiate the dialog between clients and servers by requesting a service. Servers typically wait passively for a request from a client.
The server may reside on the same machine as the client or on a different machine across a network. Within client/server software, the location of the server is usually masked or hidden from the client by redirecting the service calls when required. A program may be a client, a server, or both.
The ideal client/server software is independent of hardware or operating system software platforms. Users should be able to mix and match client and server platforms.
Clients and servers are loosely coupled systems which may interact through a message-passing mechanism. The message is the delivery mechanism for service requests and replies.
The server is a "specialist." A message tells a server what service is requested and it is then up to the server to determine how the service is accomplished. Servers may be upgraded without affecting the clients as long as the published message interface is not changed.
The server code and server data are typically centrally maintained, which results in cheaper maintenance and the guarding of shared data integrity. At the same time, clients remain personal and independent.
The client/server characteristics described above allow intelligence to be easily distributed across a network, and provide a framework for the design of loosely coupled network based applications.
Many data processing system manufacturers provide a programming language called a "procedures language" for use with their hardware platforms. For example, International Business Machines Corporation (IBM) of Armonk, N.Y. provides the REXX language as a system procedures language to be used with data processing systems that follow IBM's System Application Architecture (SAA). In addition to performing the procedures language role, REXX is often used as a macro language, a simple application development language, as a prototyping language, and in personal computing. A procedures language may also be known as a glue language, a system extension language, an EXEC language, and a shell language.
Code written in a procedures language is often utilized to control the running environment, by providing an outer structure for what needs to be done or controlled. The role of a procedures language may be characterized by the fact that residual text is sent to a specified environment, such as the operating system's command line interface, for further interpretation. This includes system-specific commands, as well as commands which may be utilized to invoke whole applications. The procedures language allows programmers to write code that may be utilized personalize their data processing system environments. Code written in procedures language may also allow access to other programs or data.
In the role of a macro language, the procedures language interfaces with the command line interface presented by an application to the application user. For example, the procedures language may interface with a text editor, such as XEDIT on VM or KEDIT on the PC. This allows the application user to utilize the procedures language to personalize the application by grouping together application commands in conjunction with procedures language logic and, if needed, system commands. Users may utilize a sequence of commands presented by the procedures language to the application to perform repetitive tasks, and extend the application user interface.
In the REXX procedures language, programs are constructed from the following basic components: (1) clauses or statements, (2) tokens, (3) expressions, (4)instructions, (5) assignments, and (6) separators. In a REXX program, each program line usually contains at least one clause or statement. REXX interprets one clause at a time. Each clause can be divided into tokens, which are typically separated by blanks. Every item delimited by blanks inside a clause is defined as a token. The special characters comma (","), semicolon (";") and colon (":") are also used as token delimiters.
An expression is composed of terms and operators. There are three varieties of terms: (1) strings, (2) symbols, and (3) function calls. Each operator acts on two terms (except for prefix operators, which act on the term following). There are four varieties of operators/operations: (1) string concatenation, (2) arithmetic operators, (3) comparative operators, and (4) logical (boolean) operators.
Instructions are identified by a REXX keyword or a group of REXX keywords specifying a particular task.
Assignments assign a variable a value. A variable is a symbol that may change value during the execution of a REXX program.
Separators are defined as special characters which indicate the ending or continuation of a clause. Normally each clause occupies one physical program line. However, multiple clauses on one line may be separated by a semicolon (";"). A clause spanning more than one line is continued with a comma (",") at the end of each line to be continued.
When a REXX program is interpreted, each clause is subjected to two processes: (1) translation and (2) execution. During translation, all comments are ignored and substitution occurs. If, during substitution, a token is identified as a variable, it is replaced by its value; variables not previously referenced are dynamically defined.
During execution, three types of clauses require action: (1) instructions which are recognized as REXX keywords are executed; (2) assignments are made; and (3) commands are executed. In such execution of system commands, strings that are not recognized as null clauses, labels, assignments, or instructions, are passed to the calling environment for execution.
REXX is usable as a command or macro language for applications which have internal commands. It is also an extremely effective programming language, because it can utilize separately compiled program packages as REXX subprograms. These capabilities are facilitated by the "REXX environment model."
In the REXX environment model, there are essentially no illegal commands or statement forms. There may, however, be expressions which are illegal syntactically. Such command and statement forms can be categorized into those which are meaningful to the REXX interpreter and those which are not. Commands or statement forms which REXX does not understand are passed to the underlying environment in which REXX is executing, using the command interface defined for the environment.
When a REXX program is invoked, the calling environment, such as CMS or XEDIT, is the default environment in which commands will be executed. For example, an EXEC file invoked from XEDIT is passed on to CMS by XEDIT, thus making CMS the calling environment. If an expression is evaluated, resulting in a character string which does not represent a legitimate REXX operation, such a character string is submitted to the "addressed" environment for execution.
After execution of the command represented by such a character string, control is returned to the REXX interpreter after setting a return code appropriate for the addressed environment. This return code is assigned to a special REXX variable, "Rc." Upon return of control to the interpreter, the value of should be evaluated to determine whether or not alternative action is required. For example, if a command is intended to invoke a program stored in another file, and that file is not found, a return code will be returned indicating that the file was not found. Typically, successful completion of a command results in RC set to zero.
At present, if a user wishes to implement client/server support in the REXX procedures language, the user may add new interface routines as function calls or as callable subroutines, both of which may require code written in a language other than REXX. On the client side, the calls should be able to identify the target server and to pass a request. On the server side, routines should be able to wait for requests from a client, and retrieve and set client variables. At present, some procedural languages, such as REXX, do not have instructions for providing a "wait-for-request" function. Nor are instructions for reading and setting variables in a client program from a server program available in some procedural languages.
When adding new instructions to a programming language, the naturalness, readability, and maintainability (for which REXX is known) should be maintained.
Therefore, the problem remaining in the prior art is to provide the user of a programming language a method and system for providing client/server support which permits a server to wait for client requests and to read and set client variables, in a manner consistent with the programming language's friendly "look and feel."